=over

=item eval EXPR
X<eval> X<try> X<catch> X<evaluate> X<parse> X<execute>
X<error, handling> X<exception, handling>

=item eval BLOCK

=item eval

C<eval> in all its forms is used to execute a little Perl program,
trapping any errors encountered so they don't crash the calling program.

Plain C<eval> with no argument is just C<eval EXPR>, where the
expression is understood to be contained in L<C<$_>|perlvar/$_>.  Thus
there are only two real C<eval> forms; the one with an EXPR is often
called "string eval".  In a string eval, the value of the expression
(which is itself determined within scalar context) is first parsed, and
if there were no errors, executed as a block within the lexical context
of the current Perl program.  This form is typically used to delay
parsing and subsequent execution of the text of EXPR until run time.
Note that the value is parsed every time the C<eval> executes.

The other form is called "block eval".  It is less general than string
eval, but the code within the BLOCK is parsed only once (at the same
time the code surrounding the C<eval> itself was parsed) and executed
within the context of the current Perl program.  This form is typically
used to trap exceptions more efficiently than the first, while also
providing the benefit of checking the code within BLOCK at compile time.
BLOCK is parsed and compiled just once.  Since errors are trapped, it
often is used to check if a given feature is available.

In both forms, the value returned is the value of the last expression
evaluated inside the mini-program; a return statement may also be used, just
as with subroutines.  The expression providing the return value is evaluated
in void, scalar, or list context, depending on the context of the
C<eval> itself.  See L<C<wantarray>|/wantarray> for more
on how the evaluation context can be determined.

If there is a syntax error or runtime error, or a L<C<die>|/die LIST>
statement is executed, C<eval> returns
L<C<undef>|/undef EXPR> in scalar context, or an empty list in list
context, and L<C<$@>|perlvar/$@> is set to the error message.  (Prior to
5.16, a bug caused L<C<undef>|/undef EXPR> to be returned in list
context for syntax errors, but not for runtime errors.) If there was no
error, L<C<$@>|perlvar/$@> is set to the empty string.  A control flow
operator like L<C<last>|/last LABEL> or L<C<goto>|/goto LABEL> can
bypass the setting of L<C<$@>|perlvar/$@>.  Beware that using
C<eval> neither silences Perl from printing warnings to
STDERR, nor does it stuff the text of warning messages into
L<C<$@>|perlvar/$@>.  To do either of those, you have to use the
L<C<$SIG{__WARN__}>|perlvar/%SIG> facility, or turn off warnings inside
the BLOCK or EXPR using S<C<no warnings 'all'>>.  See
L<C<warn>|/warn LIST>, L<perlvar>, and L<warnings>.

Note that, because C<eval> traps otherwise-fatal errors,
it is useful for determining whether a particular feature (such as
L<C<socket>|/socket SOCKET,DOMAIN,TYPE,PROTOCOL> or
L<C<symlink>|/symlink OLDFILE,NEWFILE>) is implemented.  It is also
Perl's exception-trapping mechanism, where the L<C<die>|/die LIST>
operator is used to raise exceptions.

Before Perl 5.14, the assignment to L<C<$@>|perlvar/$@> occurred before
restoration
of localized variables, which means that for your code to run on older
versions, a temporary is required if you want to mask some, but not all
errors:

 # alter $@ on nefarious repugnancy only
 {
    my $e;
    {
      local $@; # protect existing $@
      eval { test_repugnancy() };
      # $@ =~ /nefarious/ and die $@; # Perl 5.14 and higher only
      $@ =~ /nefarious/ and $e = $@;
    }
    die $e if defined $e
 }

There are some different considerations for each form:

=over 4

=item String eval

Since the return value of EXPR is executed as a block within the lexical
context of the current Perl program, any outer lexical variables are
visible to it, and any package variable settings or subroutine and
format definitions remain afterwards.

=over 4

=item Under the L<C<"unicode_eval"> feature|feature/The 'unicode_eval' and 'evalbytes' features>

If this feature is enabled (which is the default under a C<use 5.16> or
higher declaration), EXPR is considered to be
in the same encoding as the surrounding program.  Thus if
S<L<C<use utf8>|utf8>> is in effect, the string will be treated as being
UTF-8 encoded.  Otherwise, the string is considered to be a sequence of
independent bytes.  Bytes that correspond to ASCII-range code points
will have their normal meanings for operators in the string.  The
treatment of the other bytes depends on if the
L<C<'unicode_strings"> feature|feature/The 'unicode_strings' feature> is
in effect.

In a plain C<eval> without an EXPR argument, being in S<C<use utf8>> or
not is irrelevant; the UTF-8ness of C<$_> itself determines the
behavior.

Any S<C<use utf8>> or S<C<no utf8>> declarations within the string have
no effect, and source filters are forbidden.  (C<unicode_strings>,
however, can appear within the string.)  See also the
L<C<evalbytes>|/evalbytes EXPR> operator, which works properly with
source filters.

Variables defined outside the C<eval> and used inside it retain their
original UTF-8ness.  Everything inside the string follows the normal
rules for a Perl program with the given state of S<C<use utf8>>.

=item Outside the C<"unicode_eval"> feature

In this case, the behavior is problematic and is not so easily
described.  Here are two bugs that cannot easily be fixed without
breaking existing programs:

=over 4

=item *

It can lose track of whether something should be encoded as UTF-8 or
not.

=item *

Source filters activated within C<eval> leak out into whichever file
scope is currently being compiled.  To give an example with the CPAN module
L<Semi::Semicolons>:

 BEGIN { eval "use Semi::Semicolons; # not filtered" }
 # filtered here!

L<C<evalbytes>|/evalbytes EXPR> fixes that to work the way one would
expect:

 use feature "evalbytes";
 BEGIN { evalbytes "use Semi::Semicolons; # filtered" }
 # not filtered

=back

=back

Problems can arise if the string expands a scalar containing a floating
point number.  That scalar can expand to letters, such as C<"NaN"> or
C<"Infinity">; or, within the scope of a L<C<use locale>|locale>, the
decimal point character may be something other than a dot (such as a
comma).  None of these are likely to parse as you are likely expecting.

You should be especially careful to remember what's being looked at
when:

    eval $x;        # CASE 1
    eval "$x";      # CASE 2

    eval '$x';      # CASE 3
    eval { $x };    # CASE 4

    eval "\$$x++";  # CASE 5
    $$x++;          # CASE 6

Cases 1 and 2 above behave identically: they run the code contained in
the variable $x.  (Although case 2 has misleading double quotes making
the reader wonder what else might be happening (nothing is).)  Cases 3
and 4 likewise behave in the same way: they run the code C<'$x'>, which
does nothing but return the value of $x.  (Case 4 is preferred for
purely visual reasons, but it also has the advantage of compiling at
compile-time instead of at run-time.)  Case 5 is a place where
normally you I<would> like to use double quotes, except that in this
particular situation, you can just use symbolic references instead, as
in case 6.

An C<eval ''> executed within a subroutine defined
in the C<DB> package doesn't see the usual
surrounding lexical scope, but rather the scope of the first non-DB piece
of code that called it.  You don't normally need to worry about this unless
you are writing a Perl debugger.

The final semicolon, if any, may be omitted from the value of EXPR.

=item Block eval

If the code to be executed doesn't vary, you may use the eval-BLOCK
form to trap run-time errors without incurring the penalty of
recompiling each time.  The error, if any, is still returned in
L<C<$@>|perlvar/$@>.
Examples:

    # make divide-by-zero nonfatal
    eval { $answer = $a / $b; }; warn $@ if $@;

    # same thing, but less efficient
    eval '$answer = $a / $b'; warn $@ if $@;

    # a compile-time error
    eval { $answer = }; # WRONG

    # a run-time error
    eval '$answer =';   # sets $@

If you want to trap errors when loading an XS module, some problems with
the binary interface (such as Perl version skew) may be fatal even with
C<eval> unless C<$ENV{PERL_DL_NONLAZY}> is set.  See
L<perlrun|perlrun/PERL_DL_NONLAZY>.

Using the C<eval {}> form as an exception trap in libraries does have some
issues.  Due to the current arguably broken state of C<__DIE__> hooks, you
may wish not to trigger any C<__DIE__> hooks that user code may have installed.
You can use the C<local $SIG{__DIE__}> construct for this purpose,
as this example shows:

    # a private exception trap for divide-by-zero
    eval { local $SIG{'__DIE__'}; $answer = $a / $b; };
    warn $@ if $@;

This is especially significant, given that C<__DIE__> hooks can call
L<C<die>|/die LIST> again, which has the effect of changing their error
messages:

    # __DIE__ hooks may modify error messages
    {
       local $SIG{'__DIE__'} =
              sub { (my $x = $_[0]) =~ s/foo/bar/g; die $x };
       eval { die "foo lives here" };
       print $@ if $@;                # prints "bar lives here"
    }

Because this promotes action at a distance, this counterintuitive behavior
may be fixed in a future release.

C<eval BLOCK> does I<not> count as a loop, so the loop control statements
L<C<next>|/next LABEL>, L<C<last>|/last LABEL>, or
L<C<redo>|/redo LABEL> cannot be used to leave or restart the block.

The final semicolon, if any, may be omitted from within the BLOCK.

=back

=back